---
title: FAQ
---

## Which Go versions are supported

The same as the Go team (the 2 latest minor versions).

Basically, golangci-lint supports Go versions lower or equal to the Go version used to compile it.

New versions of Go are not automatically supported because, in addition of the Go version used to build it,
some linters and/or internal pieces of golangci-lint could need to be adapted to support this new Go version.

## How to use `golangci-lint` in CI

Run `golangci-lint` in CI and check the exit code. If it's non-zero - fail the build.

See [how to properly install `golangci-lint` in CI](/welcome/install/#ci-installation)

## `golangci-lint` doesn't work

1. Please, ensure you are using the latest binary release.
2. Run it with `-v` option and check the output.
3. If it doesn't help create a [GitHub issue](https://github.com/golangci/golangci-lint/issues/new/choose) with the output from the error and #2 above.

## Why do you have `typecheck` errors?

`typecheck` is like a front-end for the Go compiler errors.
Compilation errors are identified/labeled as reports of `typecheck` but they are not produced by a linter called `typecheck`.

`typecheck` is not a linter, it doesn't perform any analysis,
it's just a way to identify, parse, and display compiling errors (produced by the `types.Checker`) and some linter errors.

It cannot be disabled because of that.

Of course, this is just as good as the compiler itself and a lot of compilation issues will not properly show where in the code your error lies.

As a consequence, the code to analyze should compile.
It means that if you try to run an analysis on a single file or a group of files or a package or a group of packages,
with dependencies on other files or packages of your project, as it doesn't compile (because of the missing pieces of code),
it also cannot be analyzed.

If there are `typecheck` errors, golangci-lint will not be able to produce other reports because that kind of error doesn't allow it to perform any analysis.

How to troubleshoot:

- [ ] Ensure the version of `golangci-lint` is built with a compatible version of Go.
- [ ] Ensure dependencies are up-to-date with `go mod tidy`.
- [ ] Ensure building works with `go run ./...`/`go build ./...` - whole package.
- [ ] Ensure you are not running an analysis on code that depends on files/packages outside the scope of the analyzed elements.
- [ ] If using CGO, ensure all require system libraries are installed.

## Why is it not possible to skip/ignore `typecheck` errors?

For mainly the same reasons that you cannot compile when you have a compiler error.

`typecheck` errors are reported in the same style as linter reports/issues,
but are completely different because they are related to problems that block the analysis (`typecheck` is not a linter).

When there are `typecheck` errors,
most linters are not able to perform the analysis,
and they simply do not produce any reports,
so it's not possible to skip/ignore `typecheck` errors.

## Why running with `--fast` is slow on the first run?

Because the first run caches type information. All subsequent runs will be fast.
Usually this options is used during development on local machine and compilation was already performed.

## How do you add a custom linter?

You can integrate it yourself, see this [manual](/contributing/new-linters/).
Or you can create a [GitHub Issue](https://github.com/golangci/golangci-lint/issues/new?assignees=&labels=enhancement&projects=&template=feature_request.yml) and we will integrate when time permits.

## How to integrate `golangci-lint` into large project with thousands of issues

We are sure that every project can easily integrate `golangci-lint`, even the large one.

The idea is to not fix all existing issues.
Fix only newly added issue: issues in new code.

To do this setup CI to run `golangci-lint` with options `--new-from-merge-base=main` or `--new-from-rev=HEAD~1`.

Also, take a look at option `--new`,
but consider that CI scripts that generate unstaged files will make `--new` only point out issues in those files and not in the last commit.
In that regard `--new-from-merge-base=main` or `--new-from-rev=HEAD~1` are safer.

By doing this you won't create new issues in your code and can choose fix existing issues (or not).

## Why `--new-from-xxx` don't seem to be working in some cases?

The options `--new-from-merge-base`, `--new-from-rev`, and `--new-from-patch` work by comparing `git diff` output and issues.

If an issue is not reported as the same line as the changes then the issue will be skipped.
This is the line of the issue is not inside the lines changed.

To fix that you have to use the option `--whole-files`.

The side effect is the issues inside file that contains changes but not directly related to the changes themselves will be reported.
